文 | 大东
出品 | OSC开源社区（ID：oschina2013)
近日，微软 Edge 团队发布了一则云游戏相关公告，其中引用了一个来自社区的项目却没有标明来源，遭到了项目原作者的声讨。
据这名来自加拿大蒙特利尔的开发者（网名：TheEvilSkeleton）介绍，微软最近在 Steam 平台上发布了一篇关于 Xbox 云游戏的使用攻略，原文中引用了他个人开发、一些社区伙伴参与贡献的 Edge Flatpak 项目。微软方面不仅没有标明项目来源，且行文的方式误导读者相信微软本身就是 Edge Flatpak 的维护者，这让他和该项目的其他贡献者感到意外。 “我过去曾联系过微软，询问他们是否有兴趣正式维护 Flatpak 项目，但我没有收到官方答复。”TheEvilSkeleton 在指控信中解释说，“作为 Edge Flatpak 项目的维护者，我本人很乐意加入微软工作，前提是微软愿意从官方角度来积极维护 Flatpak 项目，因为我已经有维护它的经验，这也能为微软省下再雇佣其他人来做这件事的麻烦。在过去一年多的时间里，我很高兴地让 Edge Flatpak 项目保持活跃并自愿更新，即便没有得到微软的官方支持。但无论如何，忽视我们的努力是不对的。” 该项目作者认为，如果这是微软 Edge 团队的一个疏忽，那么在他看来，如果他们不首先在内部核实，看看究竟是谁维护了 Edge Flatpak 项目就发出这样容易误导读者的公告，是非常“鲁莽”的。 最后，他对微软方面提出了两点诉求，首先是希望微软能够正确地感谢 Edge Flatpak 项目实际的维护者和贡献者；其次是希望微软方面能够正式参与维护 Edge Flatpak 项目，“要么和我们共同维护，要么自己独立维护，这将使更多的公司和维护者对采用 Flatpak 及其相关技术感兴趣并参与其中。微软还可以向 Flatpak 社区捐款，以使在 Linux 上轻松共享 Edge 成为可能。” 事件曝光后，迅速在国外 reddit 论坛等社交媒体上发酵，不少网友跟帖支持 Edge Flatpak 项目原作者维权。 很快，微软 Edge 团队产品经理 Kyle Pflug 通过电子邮件与 Edge Flatpak 项目作者取得联系，证实这确实是 Edge 团队的一个疏忽，并“真诚地道歉”。Kyle 代表微软 Edge 团队与项目原作者进行了沟通，明确了 Edge Flatpak 项目来自社区并修改了此前发布的文章内容，但并没有承诺微软方面是否会对 Flatpak 项目提供人力或资金方面的官方支持。 虽然事件以 Edge Flatpak 项目原作者维权成功暂告一段落，但微软在此次事件中表现出来的傲慢和“白嫖”态度还是引发了很多开源爱好者的不满。不少网友强烈谴责微软是“窃取”开源社区成果的惯犯，并列出了近年来微软犯过的类似案例。2020 年 5 月，微软在 Build 2020 大会上发布了新的软件包管理工具 WinGet，并将其开源。而该工具实际上抄袭自一名居住在加拿大温哥华的软件工程师 Keivan Beigi 维护的 AppGet 项目。当时，来自微软 App 事业部的产品经理曾和 Keivan 表达了对 AppGet 项目的兴趣，并以邀请其加入微软团队为前提，就 AppGet 项目的设计思路进行了多次深入交流，时间跨度长达 5 个月。但最后微软方面就与 Keivan 突然失联，并于半年后发布了设计思路、代码结构均与 AppGet 高度雷同的 WinGet 项目。AppGet 作者 Keivan 在社交媒体揭露这件事后，微软方面同样仅仅是派产品经理出面承认了 WinGet 项目的思路确实“借鉴”于 AppGet，表达了对 Keivan 等 AppGet 项目贡献者的谢意，但并没有就抄袭事件本身对 Keivan 本人和 AppGet 项目团队进行任何实质性的补偿和支持。 在更早的 2018 年 6 月，微软也曝出过类似的抄袭事件。当时，开源的多包存储库管理工具 Lerna 作者 jamiebuilds 指责微软抄袭其代码。 jamiebuilds 表示， Lerna.js 是自己写的一个多包存储库管理工具。为让项目更好用，他对项目进行了 5 次重写，试图让架构更完善。之后某天，jamiebuilds 发现了微软推出了由许多小包组成的新设计体系，本以为是微软在项目中使用了 Lerna ，结果发现他们使用的是一个名为 “Rush” 的项目。 通过查看 Rush 项目的 Git 日志，jamiebuilds 发现该项目就是在 Lerna.js 创建几天之后创建的，jamiebuilds 对两个项目进行了对比，结果发现 Rush 的文件和目录命名、核心功能的代码都与 Lerna.js 完全相同，甚至连提交记录都是一致的，也就是说 Rush 在不断复制 Lerna 的更改，然后声称其是微软自研的产品。 jamiebuilds 称自己主动与认识的微软员工联系说明此事后，对方感到震惊并道歉，但之后并没有任何来自官方的合理解释。Rush 项目也没有去更改许可证，或者添加补充说明，而是将提交记录进行了混淆，将代码位置进行移动，并重新编写或重命名了一些函数。 jamiebuilds 提到，如果是其他人做了这件事，他或许会有点不高兴但仍然把他忽略掉。但微软这样一个万亿市值的软件业巨头做这样的事情，这令他非常生气。 这件事最后同样不了了之。目前，很多开发者普遍对于开源协议仍然不够了解。有人甚至认为：开源软件就是免费的软件，那我拿你开源的项目来用，这不很正常吗？这其实是一种误解。 在很多时候，开源社区并不排斥 fork 或 copy 项目代码，fork 后将自己修改的 BUG 或新增的功能反馈回上游社区，反而是开源社区里非常鼓励的一种行为。但微软这种抹杀原作者功劳，将社区劳动成果归功于己的行为，显然违反了开源社区应有的道德规范，同时也违反了开源协议。 开源软件与专有软件一样，都是受法律保护的。近年来发生的多起开源软件版权纠纷案例就足够引起人们对开源软件版权的重视。 实际上，开源软件的著作权既没有放弃也没有过期，作者仍然享有著作权。除了著作权外，开源软件还可能被合同法、专利法、商标法等法律所规制。在著作权法的语境下，软件代码类似于文字作品一样受到法律保护。在获得了一段源代码之后，默认情况下不能对该源代码进行改编或者再发行。而开源软件的特点在于，对于部分宽松开源协议（如 MIT、Apache 2.0）来说，在使用者承诺满足一定条件（通常包括给作者署名、附带许可证）的情况下，作者会放弃、让渡部分权利，例如允许使用者将代码改编或者再发行。 律师介绍，使用者所承诺的条件以及作者所放弃的部分权利形成了一种合同关系，更具体来讲是许可合同，在开源软件的情况下该合同也就是我们常说的开源许可证（License）。许可证是一种无需磋商的、标准化的公共合同，降低了合同的成本。 理论上来说，使用 MIT、Apache 2.0 等宽松开源许可证的项目，源代码可以被任何人拿去修改、分发、甚至闭源商业化，但必须保留项目原作者的著作权，也就是在源代码引用的部分保留项目作者的版权声明。以 MIT 许可协议为例，该协议规定，被授权人要履行 “在软件和软件的所有副本中都必须包含版权声明和许可声明” 的义务。也就是说，微软采用别人开源的项目源代码本身并没有任何问题，但其拒绝履行开源协议规定的“保护软件原作者著作权”的义务，事实上是违反了开源协议的。 尽管开源项目源代码也受到法律的保护，但个人开发者维护的开源项目在面对微软这种级别的大型企业时，往往难以维护自己的合法权益。比较大型的开源项目通常会由企业或专门成立的基金会来处理相关的法务问题，这些大型开源项目的版权属于企业或中立的开源基金会等主体，主体享有处理项目授权、更改开源协议的权利，能够随时应对项目授权问题带来的法律纠纷。 但个人开发的项目版权属于开发者自己，面对类似的侵权行为时，显然缺乏足够的人力和财力去处理这些法律纠纷，在大多数情况下只能闷声吃亏。这也是微软的三起抄袭事件受害者均为个人开发者的原因。因此，在个人在开源自己的软件作品时，一定要充分理解各类开源许可证的各项条款，在被侵权时积极维护自己的合法权益，必要时可以公开被侵权的证据寻求舆论帮助；同样的，当我们在使用开源项目的代码时，也要尊重原作者的劳动成果，自觉履行开源协议所要求的义务。首例！违反 GPL 协议致侵权，被判赔偿 50 万元